The Windows 3.x registry was so simple that most people never gave it a second thought. About the only things it contained were some file associations and a few OLE settings. You might have found a few bits and pieces of other information in there as well, but for the most part, even Windows ignored the registry.
Along came Windows NT. This product contains a registry that's so complex that you need a four-year degree just to figure out the basics. The Windows NT registry contains every piece of information about everything that the operating system needs to know. This includes equipment settings, software configuration, network setup, and all the DLLs it needs to run applications. In essence, the registry has become the central repository of information for the Windows NT operating system.
One of the biggest problems with the first few versions of the Windows NT registry was the RegEdit utility. The previous version placed the major keys in a set of overlapping windows that made editing the registry difficult at best. The new version of RegEdit provides the same hierarchical interface as that used by Windows 95. You'll find that editing is a lot less complicated and finding the information you need is a snap. Is the registry still an extremely complex environment? I don't think a simple editor modification will change the complexity of the information that the registry has to hold; if anything, the new version of Windows NT places even more information in the registry than before. Using the new editor does mean that you'll have less trouble figuring out what you're viewing, however. The new editor also allows you to reduce the complexity of the information by hiding the keys that you don't need to view. (I'll tell you more about the various registry concepts in a bit.)
The Windows NT registry also replaces two files that had bad reputations under Windows 3.x. Anyone who has spent time working with Windows 3.x knows about the fun of working with the SYSTEM.INI and WIN.INI files. The WIN.INI file holds Windows environment settings; it changes the way Windows interacts with the user. The SYSTEM.INI file contains hardware and device-driver configuration information; it changes the way Windows configures itself during startup. Of course, the distinction between these two files is somewhat blurred. For example, WIN.INI holds the serial port and printer configuration information.
These two poorly organized, cryptic files hold the vast majority of configuration information for the Windows 3.1 system. Every time the user adds an application to Windows 3.1, the application adds yet another heading or two and some additional entries to both files. On the other hand, when the user gets rid of an application, the entries don't go with it. They just sort of hang around and slow system performance. Some entries can even cause error messages or, in extreme circumstances, a system crash. Windows NT still supports these rather archaic and difficult-to-understand files, but it prefers that applications use the new registry.
Note: Windows NT copies the contents of SYSTEM.INI and WIN.INI into the registry whenever possible. The only reason that these two files exist is to meet the needs of Windows 3.x applications. You could theoretically remove both files from your hard drive if you didn't have any older applications to run. In reality, it'll be quite a while before you can get rid of either file.
The registry is a complex piece of software. Windows NT can't boot without a clean registry. Any corruption in this file will cause a host of problems even if Windows NT does manage to boot. Of course, the fact that you can't edit this file at the DOS prompt is a potential problem. (The other side of the coin is that the Windows NT Registry Editor is a lot easier to use than the old Windows 3.x combination of WIN.INI and SYSTEM.INI.)
Tip: Windows NT stores the current registry settings for each user in the NTUSER.DAT file found in each user's profile folder. The Default User folder contains the standard registry entries that Windows NT uses to create a new user. Because each user has a personal copy of the registry, any mistakes you make while editing the registry will affect only that user. You have several ways to recover from an error in editing. You can simply reverse the mistake while still in the registry. If you make a mistake and can't access the user's account when you try to enter it from the Log On dialog box, you can always log on as the administrator and copy the registry file for a similar user to the damaged user's profile folder. You can also delete the user and add him back, which copies the Default User's registry to the new profile folder. A fourth option is restoring a copy of the damaged registry file from a backup. Obviously, there's one particular user whose registry file you'll never want to edit. Because just about every form of registry access requires an administrator account, damaging this registry file is one way to lock yourself out of the system. With that in mind, I always make sure that every machine has two users with full administrator rights: the administrator and myself (or a designated representative).
Warning: Unlike in Windows 95, the version of RegEdit that comes with Windows NT doesn't provide any form of command-line (that is, DOS) interface. You can't edit the contents of the registry without a running copy of Windows NT. In addition, the registry in Windows 95 is incompatible with that found in Windows NT. Don't attempt to use the Windows 95 version of RegEdit to modify the Windows NT registry from the command line (from the DOS prompt). You can use the Windows 95 version of the Registry Editor to edit the Windows NT registry from a remote location in its GUI modefrom within Windows. Likewise, you can use the Windows NT version of RegEdit to change a Windows 95 registry.
Knowing that the registry contains a lot of information and is easy to edit still doesn't tell you what it can do for you. When was the last time you used the Explorer to check out your hard drive? I use it a lot because it provides an easy way to find what I need. The registry can help you make Explorer easier to use. One of my favorite ways to use it for Explorer modifications is to create multiple associations for the same file type. Suppose you want to associate a graphics editor with .PCX and .BMP files. This isn't too difficult. What if each file type requires a different set of command-line switches, however? Now you get into an area where using the registry can really help. Using the registry to edit these entries can help you customize file access.
Note: You should add the Registry Editor, RegEdit, to your Start menu before proceeding. (The new Windows NT version of the Registry Editor is REGEDIT.EXE; the old version is REGEDIT32.EXE.) It helps to look at the actual registry entries as you read about them. I also present some exercises that will help you better understand the inner workings of the registry. See Chapter 2, "Exploring the Interface," if you need information about adding new applications to the Start menu.
It's time to take a look at how the registry is organized. To start the Registry Editor, simply open RegEdit as you would any other application on the Start menu. You'll probably get a lot more out of the detailed discussion that follows if you open the Registry Editor now. Using the Registry Editor to see how Windows NT arranges the various entries can make using it a lot easier in an emergency.
Note: Windows NT provides a higher level of security than other versions of Windows do. You might find that one or more of the registry entries I describe in this chapter are missing from your registry display if the network administrator made them inaccessible to you. In fact, the network administrator can make the registry completely inaccessible if he wants to do so. Make sure you have the right access before you attempt any procedure in this chapter.
I always step lightly when it comes to the registry. You might want to follow the same procedure I use to back up the registry before you go much further. The big advantage to the following method is that it produces a text file that you can view with any text editor. (The file is huge, so Notepad won't handle it, but Wordpad will.) You can use this backup file to restore the registry later if you run into difficulty. Unfortunately, this method won't help much if you permanently destroy the registry and reboot the machine. Windows NT needs a clean registry to boot. To preserve a clean, bootable copy of the registry, you need to copy the NTUSER.DAT files to a safe location.
Warning: RegEdit is an application designed to assist experienced users in changing Windows NT and associated application behavior. Although it enables you to enhance system performance and make applications easier to use, it can cause unexpected results when misused. Never edit an entry unless you know what that entry is for. Failure to observe this precaution can result in data loss and even prevent your system from booting the next time you start Windows NT.
Tip: The Windows NT Resource Kit contains four special registry-related files. One is a help file that documents all the default registry entries in detail. This documentation doesn't include any of the entries that an application might make outside the standard entries. Two of the three utility programs enable you to backup and restore the registry. A third program allows you to make registry entries using a script file. This comes in handy for adding new registry entries automatically when a user logs into the network. Needless to say, you'll want to use this feature with extreme care.
You use the RegEdit utility to view and change the contents of the registry. It displays the registry in the Windows 95 style format shown in Figure 7.3. Windows NT uses NTUSER.DAT to store the registry information, unlike the two file system (SYSTEM.DAT and USER.DAT) used by Windows 95. Even though the RegEdit display might seem a bit difficult to understand at first, it's really not. The big difference between the registry and the Windows 3.x alternative of SYSTEM.INI and WIN.INI is that the registry uses a hierarchical organization and plain English descriptions that you'll find easy to edit and maintain. Every application you add will add entries to this file, but the file's organization makes it easy for an application to remove the entries when you uninstall it. Even if you install an older application that doesn't understand the registry, you can still remove its entries with ease.
Figure 7.3. A typical RegEdit opening screen. Each HKEY key controls a different part of the Windows setup.
The Windows NT registry uses two types of entries to maintain its organization: keys and values. Keys are RegEdit topics. Think of a key as the heading that tells you what a particular section contains. Looking at all the keys provides an outline for a particular topic. The topics could range from the setup of each drive in the system to the file associations needed to configure the machine. The key at the top of the hierarchy usually contains generic information. Each subkey provides a little more detail about that particular topic. Keys always appear on the left side of the RegEdit window.
Values are the definitions of a RegEdit topic; they describe the key in some way. Think of a value as the text that fills out the heading provided by a key. Values are like the text in this book, whereas keys are the headings that organize the text. A value can contain just about anything. The value for a file association key can tell you which application Windows NT will start when you double-click a file that has that extension in Explorer, for example. A value could tell you which interrupt and I/O port settings a piece of hardware uses as well. You'll find the value you need using the keys, but you'll find the actual information you need by reading the values.
The three types of values are binary, string, and DWORD. Usually, only applications use the binary and DWORD value types. Values usually store configuration data in a format that can't be understood by humans. Some applications use DWORD or binary values to store data. You might find the score from your last game of FreeCell here, for example. String values provide a lot of information about the application and how it's configured. Hardware usually uses string values as well for interrupt and port information. Values always appear on the right side of the RegEdit window.
Key entries also have a superset. I differentiate these particular keys from the rest because they are the major headings in the registry. During the rest of this discussion, I refer to these special keys as categories. Think of categories as the chapter titles in a book. You need to go to the right chapter before you can find the right type of information. Information in one category might appear in the same order and at the same level in another category. The difference between the two is when Windows NT uses the entries in one category versus another.
Categories are the five main keys under the My Computer key. Categories divide the registry into five main areas:
Each category contains a specific type of information. As you can see, the Windows NT registry is much enhanced from its Windows 3.1 counterpart (it uses about the same organization as the Windows 95 registryat least when you view the main keys). Even though Windows NT still has to use the infamous SYSTEM.INI and WIN.INI files for antiquated applications, the use of the registry for all other purposes does reduce the user's workload. Eventually, all applications will use the registry to store their configuration data. The next few sections of the chapter describe these categories in detail.
The HKEY_CLASSES_ROOT category has two distinct types of entries. The first key type (remember, a key is a RegEdit topic) is a file extension. Think of all the three-letter extensions you've used, such as .DOC and .TXT. Windows NT still uses them to differentiate one file type from another. It also uses them to associate that file type with a specific action. Even though you can't do anything with a file that uses the DLL extension, for example, it appears in this list because Windows NT needs to associate DLLs with an executable file type. The second entry type is the association itself. The file extension entries normally associate a data file with an application or an executable file with a specific Windows NT function. Below the association key are entries for the menus you see when you right-click an entry in the Explorer. It also contains keys that determine what type of icon to display and other parameters associated with a particular file type. Figure 7.4 shows the typical HKEY_CLASSES_ROOT organization.
Figure 7.4. A typical HKEY_CLASSES_ROOT display. Notice the distinct difference between file extension and file association keys.
Don't let the deceptively simple appearance of this category fool you; it's one of the truly well designed areas of the registry. A third type of key is hidden within the two that are obvious to the casual observer. For now, take an in-depth look at the two more obvious key types. The following sections describes these entries in detail. I follow this discussion with a little more detailed information about the mysterious third key type.
Tip: You should always change your application file entries to make your working environment as efficient as possible. You should never change an executable file association, however. Changing an executable file extension such as .DLL could make it hard for Windows NT to start your applications or could even crash the system. The section "Modifying File Associations" later in this chapter looks at the procedure for changing an application file association.
Some file extensions such as .TXT provide a ShellX subkey (see Figure 7.5). In the case of .TXT and .DOC, the standard subkey is ShellNew (the most common key). The term ShellX means "shell extension." I like to think of it as an automated method of extending the functionality of Windows as a whole. When you right-click the Desktop and look at the New option on the context menu, all the types of files you can create are the result of shell extensions. Even though ShellNew is the most common type of shell extension, a variety of other shell extensions are available. The actual number is limited only by your application vendor. Microsoft Excel provides no less than three different shell extension entries for the XLS file extension, for example.
Figure 7.5. The shell extension is a powerful OLE 2 feature that few applications implement.
A shell extension is an OLE hook into Windows NT. Only an application that supports OLE 2 extensions can place a ShellX key into the registry; don't add one of these keys on your own. When you see this key, you know that the application provides some type of extended OLE-related functionality. If you double-click a shortcut to a data file that no longer exists, for example, an application with the ShellNew shell extension will ask if you want to create a new file of the same type. (If you look at the values associated with ShellNew, there's always a NullFile entry that tells the shell extension what type of file to create.)
Tip: Sometimes a file type won't appear on the context menu even though the application provides support for it. Most of the time, it happens with 16-bit applications that don't install correctly. You can use the shell extension behavior to create new files as if the context menu entry did exist. All you need to do is create a temporary file, place a shortcut to it on your Desktop, and erase the temporary file. (Make certain that the application provides a ShellNew shell extension before you do this.) Whenever you double-click the shortcut, your application will create a new file for you. This behavior also works if you place the file shortcut in the Start menu folder.
The registry also has other, more generic, shell extensions. The * extension has a generic Shellex subkey, for example. Below this, you'll see a PropertySheetHandler key and a 128-digit key that looks like some kind of secret code. Actually, the 128-digit value is a secret code. It's a reference identifier for the DLL (a type of application) that takes care of the * extension. You'll find this key under the CLSID key. (CLSID stands for "class identifier.") The secret code is for the "OLE Docfile Property Page." Looking at the value of the next key will tell you it exists in DOCPROP.DLL. This DLL provides the dialog box that asks which application you want to use to open a file when no registry entry is associated with that extension.
As you can see, shell extensions are a powerful addition to the Windows NT registry. You should never change or delete shell extensions; let the application take care of them for you.
Windows NT provides both OLE 1 and OLE 2 support; so do many of the applications. To show you just how organized the registry is, the OLE 1 and OLE 2 entries appear in different areas. You can always tell what kind of OLE support an application provides by checking its registry entries. If you see registry entries in one area of the registry, you know that the application provides OLE 1 support. Registry entries in a second area of the registry show that the application provides OLE 2 support. In fact, the registry will often tell you more than the application's documentation does. You might find by looking at the registry that the application supports certain verbs. A verb serves the same function in OLE as it does in a sentence; it represents some type of action that you can perform using the OLE capabilities of the application. I'll tell you a little more about verbs later on. Windows always places OLE 1 support information in the file association area. (I'll show you where the OLE 2 support appears in the registry after I discuss at OLE 1.) Figure 7.6 shows a typical setup, but the actual setup varies between applications. Table 7.1 describes the various entries in this area (plus a few not supported by this particular application). The OLE support provided by each application on your machine will probably differ from the one shown in the figure; this is only a sample for you to look at right now. Table 7.1 lists all the potential OLE 1 entries you might find. I don't think any application uses them all.
Figure 7.6. Windows places OLE 1 support in the file association area of the registry.
Entry | Description |
CLSID | This is actually part of the OLE 2 entry even though it appears in the OLE 1 section. It's a pointer to an entry in the CLSID section of the category. C programmers use a special application to generate this 128-digit "magic number." If you look for this number under the My Computer | HKEY_CLASSES_ROOT | CLSID key (as you do in just a bit), you find the OLE 2 entries for this file association. |
Insertable | Usually, you won't see any value associated with this key. A blank value means that Windows can place this file association in the Insert Object (or equivalent) dialog box provided by many applications, such as Word for Windows. Some OLE 1 objects aren't insertable for a variety of reasons. |
Protocol | This is a header key (think of it as a heading in a book, a means to group like information together in one place). Underneath it, you'll find all the standard actions that this OLE 1 application can perform. The only supported function in most cases is a standard file edit. |
StdFileEditing | This key is another header. In this case, it's the heading for all the keys that will define a particular actionstandard file editing. |
Server | This key contains the name of the application Windows will call to service any OLE 1 calls for this file association. The string always includes the application's name, extension, and path. If you ever run into a situation in which your OLE links worked yesterday but won't work today, check this value to make certain the path matches the actual application location. |
Verb | Several verbs are associated with an OLE 1 object. Each verb defines a specific action that the server will perform. This key doesn't have a value associated with it; its sole purpose is to organize actual verb entries. A client application can use only the verbs that are defined for a specific server. |
3 = Hide, 0, 1 | |
This verb allows the client application to hide the server window. The first number following the verb is a menu flag. The second number is the verb flag. As a user, you don't need to worry about either value as long as you supply the values shown here (or use the settings provided by the vendor). | |
2 = Open, 0, 1 | |
This verb allows the client to open the server in a separate window rather than allow it to take over the client window. | |
1 = Show, 0, 1 | |
A client would use this verb to display the server window in its preferred state. The whole idea of a state can get to be quite complex. Think of it as the way the window looks, and you'll have a pretty good idea of what to expect from a user's point of view. | |
0 = &Edit, 0, 2 | |
Every server provides this verb. It allows the client to call the server to edit the object. | |
1 = &Play, 0, 3 | |
The only time you'll see this verb is when you're looking at some form of multimedia object. | |
RequestDataFormats | This entry allows the server to define what data formats it supports for retrieval purposes. |
SetDataFormats | This entry allows the server to define what data formats it supports for storage purposes. |
While you're still looking at this OLE 1 entry, you'll notice that I didn't cover anything under the Shell key. Each of these entries defines an action you can perform on the file using Explorer. The shell key is a refinement of the same entry used for file associations by File Manager. The entries defined here will appear on the context menu for each file of that type. The section "Explorer: Borrowed from Windows 95" in Chapter 2 looked at the actual process of defining a file association with Explorer. I also cover a registry-specific technique later in this chapter.
Now it's time to look at the OLE 2 part of the registry. You'll find these entries under the HKEY_CLASSES_ROOT | CLSID key. Each of the 128-digit numbers here represents a specific class (a programmer's term for a specific type of object) of information. Not all entries under the HKEY_CLASSES_ROOT | CLSID key are OLE 2 entries, but some of them are. You'll also find that not every application supports OLE 2. Your first clue that CorelChart supports it is the CLSID entry in the OLE 1 section. (I mentioned the HKEY_CLASSES_ROOT | CorelChart5 | CLSID key in Table 7.1 and you saw it in Figure 7.6.) The HKEY_CLASSES_ROOT | CorelChart5 | CLSID entry is a pointer to the OLE 2 entry under the HKEY_CLASSES_ROOT | CLSID key. Figure 7.7 shows this key for CorelChartthe same application I used to describe an OLE 1 registry entry. Table 7.2 describes these entries in detail. An application doesn't necessarily need to provide every entry that I describe in Table 7.2 in the registry. It depends on what OLE 2 features the application vendor decided to support. You can use these registry entries to determine the capabilities of your application, just like you can with OLE 1.
Figure 7.7. Windows places OLE 2 support in the file association area of the registry.
Entry | Description |
AuxUserType | This key is a heading for the user type keys that follow: |
2: The 2 AuxUserType always contains the short name for the application. A client can use this name in a listbox to identify the object's owner. | |
3: This key contains the full name of the application that created the object. Like the 2 key, a client could use the 3 key value to provide an English application name for the object. | |
DataFormats | This key is a heading for all the data format keys that follow: |
GetSet: This key is a subheading for all the data formats the server can store and retrieve. An OLE server such as Word for Windows, for example, would support a DOC, RTF, and standard text format. Its OLE 2 entries would reflect this fact. Each entry below this one defines a specific format type. | |
n = format, aspect, medium, flag: Each of the sequentially numbered keys contains a different format. format contains the type of format as a string. You might find some as easy to read here as Rich Text Format or as cryptic as Embed_Source. In every case, this string tells you the name of the format that the application supports. The client displays this string (for get formats) in the dialog box where you select the format you want to use when performing a Paste Special command. aspect tells the client what display orientation the object supports. This usually means portrait or landscape. You'll usually find a value of 1 here for portrait. medium contains the supported format as a computer-readable number. flag tells the client whether this is a get, set, or both format; a value of 1 is get, a value of 2 is set, and a value of 3 is both. | |
DefaultFile: This entry works much like GetSet, except it identifies the default file format for this particular object. | |
DefaultIcon: The value of this key tells the client which application icon to use when displaying the object as an icon. | |
InProcHandler | This key contains the name of the in process handler. In most cases, this is OLE2.DLL unless the application provides its own OLE 2 handler. (A handler is a special program that helps two programs communicate.) |
Insertable | Usually, you won't see any value associated with this key. A blank value means that Windows can place this file association in the Insert Object (or equivalent) dialog box provided by many applications such as Word for Windows. Some OLE 1 objects aren't insertable for a variety of reasons. |
LocalServer | Every OLE 2 object must have a server. This key contains the name of the server on the local machine. Because OLE 2 doesn't support RPCs (remote procedure calls), you'll always need a local server. |
MiscStatus | This key contains the default value for all data format aspects. |
ProgID | The program identifier is a pointer back to the file association that this class identifier belongs to. The file association is always a character string of some sort. It's the same string that you look for when you try to find the file association that goes with a file extension in the HKEY_CLASSES_ROOT category. If you looked at the ProgID value for Corel Chart, for example, you would see CorelChart5. That's the same value in Figure 7.6 as the first key for the file association. |
Verb | Several verbs are associated with an OLE 2 object. Each verb defines a specific action that the server will perform. This key doesn't have a value associated with it; its sole purpose is to organize actual verb entries. A client application can use only the verbs that are defined for a specific server. See Table 7.1 for a list of verbs and their meanings. |
InProcServer | This is a special form of OLE server. Instead of calling the application that created the object, the client calls a DLL to handle any necessary display or edit functions. This has the advantage of speed; a DLL is faster than calling the executable. The programmer has to do a lot more coding to make this kind of interface work, though. |
TreatAs | When this key is present, it contains the CLSID for another file format. The client can treat the current file format like the specified file format. If you looked at the Paintbrush Picture OLE 2 entry, for example, you would find a TreatAs value with the same 128-digit value as a Bitmap Image. This tells you that Windows 95 uses the same application to service Paintbrush Picture files as it does for Bitmap Image files. A little more research would tell you that the OLE 2 server for Paintbrush Pictures is Microsoft Paint. |
AutoTreatAs | This key forces the client to treat the current file format the same way it would treat the file format specified by the CLSID. From a user's perspective, it works just like the TreatAs entry described previously. |
AutoConvert | Some objects' context menus contain a Convert option. This key enables you to automatically convert the current file format to the one identified by CLSID. Word for Windows allows you to convert many types of data to a format that it specifically supports, for example. This conversion process changes the embedded or linked object into a Word for Windows object. In other words, it changes the data into something that Word might have created itself. |
Convertible | This key has two levels of subkeys. The first level contains two keys, Readable and Writeable. Below them are keys that contain a list of readable or writeable file formats that you can convert this file format to. You'll find that Word for Windows supports several formats, for example, including Word Document. The number of entries in this area usually varies by the number of file filters you install for the application. If you install WordPerfect file support for Word for Windows, for example, you'll likely find an entry for it here. Remember that these are OLE 2 entries. Even if an application supports another application's file format as part of a Save As option, it still might not support it for OLE purposes. |
Interfaces | This key contains a list of interfaces supported by the server. The value for this key will eventually contain the names of other ways to access the OLE server (other than from the local machine), but there aren't any applications that support it right now. This entry could contain the types of network protocols the application supports, for example. |
Looking Ahead: This chapter discusses only the registry portion of the OLE picture. Chapter 12, "DDE and OLE," provides detailed information about OLE from a user level.
The HKEY_CURRENT_USER category contains a lot of "soft" settings for your machine. These soft settings tell how to configure the Desktop and the keyboard. It also contains color settings and the configuration of the Start menu. All user-specific settings appear in this category.
The HKEY_CURRENT_USER category is slaved to the settings for the current user, the one who's logged into the machine at the time. This category is differentiated from all the user configuration entries in other parts of the registry. HKEY_CURRENT_USER is a dynamic setting category; the other user-related categories in the registry contain static information. The registry copies the contents of the current users' entries from the HKEY_USERS category into this category when they boot the machine and updates the HKEY_USERS category when they shut down.
This is the area where Windows NT obtains new setting information and places any changes you make. As you can see from Figure 7.8, the keys within the HKEY_CURRENT_USER category are pretty self explanatory in most cases. All the entries adjust some type of user-specific setting, nothing that affects a global element such as a device driver. In other words, this particular category is a scratch pad of sorts. It's very useful to remember this fact. If you make a mistake, you can always use the settings in HKEY_USERS to reset the values to their previous settings. The following sections describe each of the HKEY_CURRENT_USER keys in detail.
Figure 7.8. The HKEY_CURRENT_USER category contains all user-specific settings.
Note: Using a common setup for all users means that HKEY_CURRENT_USER settings automatically reflect the default setting in HKEY_USERS. See the "HKEY_USERS" section for more details on these settings.
Everyone likes to add a few sounds to their system to make it more interesting. The AppEvents key defines these sounds in a number of ways. Take a look at Figure 7.9 to see what the AppEvents subkeys look like. This key has two subkeys: EventLabels and Schemes. The EventLabels key holds a list of events. Each event key contains the long name of a sound event. The EmptyRecycleBin event, for example, uses "Empty Recycle Bin" as a long name. This is what Windows displays in the dialog box you use to set the sound value.
Figure 7.9. The AppEvents key controls the sounds you hear for various system events.
Tip: This registry provides the only way you can change the strings displayed in the Sounds Properties dialog box. You might want to use this option after changing the name of the Recycle Bin or other Windows components.
The Schemes key is one you'll probably want to explore. It has two subkeys. The first one is the Names key. The subkeys hold the full names of the various sound schemes you might have defined. The Apps key contains major subkeys for each kind of application that defines special sounds. The default sounds are the beeps and other general Windows noises you hear on a daily basis. If you looked at the values for each of the minor keys, you'd see the name of a sound file.
Console applications require a DOS prompt to work. A DOS window requires settings to work, just like any other part of Windows NT does. When you change the default DOS window settings, the changed settings appear under the Console key of the registry. Figure 7.10 shows a typical example of the Console key.
Figure 7.10. The Console key provides the default settings for a DOS window.
The Control Panel key is probably the most familiar registry key. Figure 7.11 shows all the subkeys that this key contains. As you can see, the Control Panel key doesn't contain subkeys for each icon in the control, but it does contain keys for all the icons that control user-specific settings. The following list describes these subkeys in more detail.
Figure 7.11. The Control Panel key contains subkeys for every user-specific feature on the Control Panel.
Tip: If you want to share your color schemes with someone else, you can export this key using the same procedure you use to save the registry. Instead of saving the entire registry, save only the Schemes branch. When the other person imports your .REG file, he'll have the same color schemes you do.
Tip: The Color key settings provide a level of flexibility that you can't get using the standard Display Properties dialog box. Clicking the button displays the 3D object settings, for example. These settings don't provide the same precise control as the Button values in this key.
The Environment key contains the DOS environment settings. Windows stores them in hexadecimal numbers instead of plain English. It uses these values when you start a DOS session. Windows applications can request this information as well.
This registry key contains the most recently used locations of installation files. The entries you find here don't pertain to the location of software installation files but instead relate to device or service-related installation files. Installing a new set of network drivers would place an entry here, for example, but installing a new word processor wouldn't. Windows won't make this entry until you've installed some type of new device or service beyond the initial installation. Notice the special value called MRUList. This value controls the order in which Windows displays the filenames that appear in the list. If you do add an entry to the list, you also have to add it to the MRUList value.
The Keyboard Layout registry key provides information about the keyboard currently attached to the machine. It doesn't really change from user to user unless one user needs to use a different language or keyboard layout. The Preload key under the Keyboard section reflects the different languages in use. The Substitutes key reflects the keyboard layout. You could use English (United States) as a language and English (Dvorak) as a layout, for example. The Toggle key tells you which control key combination you can use to switch between languages.
Peter's Principle: Using Two Keyboard Layouts
I ran into an interesting situation the other day. Two friends were using the same machine. One uses the Dvorak layout, and the other uses the standard layout. Windows NT will enable you to install multiple languages and switch between them using the International icon on the Taskbar, but you can't switch between different layouts of the same language. How do you get around this?
Start by installing two languages using the standard keyboard dialog box. Make certain that the languages are at least compatible. To make life simple, I installed English (United States) using the standard layout and English (British) using the Dvorak layout. If you look at the HKEY_CURRENT_USER | Keyboard Layout | Preload key, you'll notice two subkeys. The value for one is 00000409 (United States), and the value for the other is 00000809 (British).
Look at the Substitutes key. You'll see a subkey for 00000809. The value in this key says 00020409. If you look up this value in the HKEY_LOCAL_MACHINE | System | CurrentControlSet | Control | Keyboard Layouts | 00020409 key, you'll see that you're using the standard Dvorak keyboard KBD driver. Our language is English, and the keyboard layout matches what the second person needs.
The only thing left to do is change the International icon list so that it matches what the machine actually has installed. If you look at it right now, it says that you have an English (United States) and an English (British) keyboard setup installed. What you really have is an English (Dvorak) keyboard installed. We need to look at the HKEY_LOCAL_MACHINE | System | CurrentControlSet | Control | NLS | Locale key. Find the 00000809 value and change it from British to Dvorak. Close the Registry Editor to make sure the change gets recorded. Now, open the Keyboard Properties dialog box in the Control Panel. Make a simple change and then change it back. Click Apply. The International icon will now show a United States and a Dvorak keyboard, making it simple for you to switch back and forth.
Unfortunately, most of the Network key's contents are network-specific. Essentially, it provides the user-specific network information your machine needs. One key remains constant across networksthe Recent key. This key contains one subkey for each of the network drives you've recently accessed. Windows NT updates it only on a session basis, so you probably won't find current information here if you maintain your network connection for a long time between sessions. Each subkey uses the full network access path for a drive. If you have a Microsoft network installed and you connect to drive C of a machine named AUX, for example, one of the subkeys might look like //AUX/DRIVE-C.
You may or may not find the RemoteAccess key in your registry. It depends on what features you choose to install. Within the key itself is an area code value and a DWORD configuration value for the Make New Connection Wizard.
Below this key, you'll find one subkey that holds the addresses you define. Each address you define has one binary value. These values include all the configuration information for that address. Obviously, you won't want to edit this value outside the Dial-Up Networking application.
The Software registry key should contain plenty of configuration information for your software. Until you upgrade to 32-bit versions of your applications, however, it'll probably contain a few default entries for Windows 95 or Windows NT-specific applications. The SSC section contains information related to the viewers. The Microsoft section contains keys for a variety of applications, whether you have them installed or not.
The registry provides the Software key to replace all those entries you used to have in WIN.INI and SYSTEM.INI. The hierarchical structure of this key makes it easy to remove application-specific information from your Windows NT installation. Of particular interest is the MS Setup (ACME) | User Info key, shown in Figure 7.12, which contains the user's name and company information. Applications look at this entry during installation. This is the only place you can change this information in Windows NT. If you need to change the user name for software installation purposes, this is the place to do it.
Figure 7.12. Many 32-bit programs use the information in the User Info key as a default during installation.
Anyone who works with Windows NT for very long soon realizes that it supports UNICODE at the lowest level. What exactly is UNICODE? It's a method for representing characters in languages that use more than 26 characters. Each character uses 16 instead of 8 bits. This particular registry entry identifies program groups that use UNICODE entries instead of the standard 8-bit characters.
The Volatile Environment area contains all of the current drive mappingsthose that you made during the current session. The reason it's called a volatile environment is that the settings will either become permanent or Windows will disregard them the next time you boot. Permanent settings get written to another area of the registry.
Windows NT provides an easy way for you to migrate from Windows 3.1. The Windows 3.1 Migration Status registry entry tracks the status of that move.
The HKEY_LOCAL_MACHINE category centers its attention on the machine hardware. This includes the drivers and configuration information required to run the hardware. Every piece of hardware appears somewhere in this section of the registry. If a piece of hardware doesn't appear here, Windows NT can't use it, even if the hardware is physically installed on your machine.
A lot of subtle information about your hardware is stored in the HKEY_LOCAL_MACHINE category. This category contains all the hardware configuration information about your machine, for example. It also provides a complete listing of the device drivers and their revision level. This section might even contain the revision information for the hardware itself. There's a distinct difference between a Pro Audio Spectrum 16+ Revision C sound board and a Revision D version of that same board, for example. Windows NT stores that difference in the registry.
Note: One of the big differences between the Windows 95 and the Windows NT registries appears in the HKEY_LOCAL_MACHINE section. The Windows 95 registry is packed with Plug and Play information; the Windows NT registry doesn't contain any at all. You'll also find hardware abstraction layer (HAL) entries in the Windows NT registrysomething that the Windows 95 registry lacks. In fact, these two sections are so different that you probably won't see too many similar entries between the two operating systems. The bottom line is that you should never mix registry entries from two different versions of Windowsespecially when it comes to hardware entries such as these.
The HKEY_LOCAL_MACHINE category does contain some software-specific information of a global nature. A 32-bit application will store the location of its Setup and Format Table (SFT) here, for example. This is a file that the application uses during installation. Some applications also use it during a setup modification. Applications such as Word for Windows NT store all their setup information in SFT tables. The only application information that does appear here is global-configurationspecific such as the SFT. Figure 7.13 shows a typical HKEY_LOCAL_MACHINE category setup. The following sections describe each key in detail.
Figure 7.13. The HKEY_LOCAL_MACHINE category contains all the hardware and device-driverspecific information about your machine.
Unlike Windows 95 where you can safely ignore the Hardware registry key, Windows NT uses it to store everything it needs to know about your hardwarethe physical device, not the drivers that we'll discuss in a few moments. This includes everything from the processors that your machine uses to the devices attached to the disk drive controllers. Figure 7.14 shows a typical hardware key setup. The following paragraphs describe the major entries in detail.
Figure 7.14. The Hardware key has much greater importance under Windows NT than it does under Windows 95.
The SECURITY registry key is network-specific. Refer to your network manuals for additional information. As a general rule, it contains pointers to files holding account and other network security-specific information. In some cases (usually with peer-to-peer networks), you won't see anything here, even if you have a network connected to your machine.
The SOFTWARE registry key contains device driver and global application information. Most applications store their specific configuration information under the Application key and any global information under another, common key. Figure 7.15 shows a typical setup. Notice that the subkeys include a variety of vendor-specific information.
Figure 7.15. The SOFTWARE key contains a wealth of information about device drivers used by your machine.
One of the interesting subkeys is Classes. Opening this key reveals a list of file extensions and associations just like the list in HKEY_CLASSES_ROOT. The purpose behind this set of keys is totally different, though. Windows NT uses this list to locate application- or device-driverspecific files instead of creating links for Explorer or providing OLE configuration information. Changing any of these keys won't affect your Explorer display. Unfortunately, it might affect how some of your applications work. The bottom line is that you shouldn't change any of these settings unless you have a good reason to do so and know exactly how the change will affect your setup.
The Description key also provides some interesting information. A default setup always contains the Microsoft remote procedure call (RPC) listing. A network could use this section to describe other links between machines as well, however. An RPC allows your machine to use the resources found on another machine. This is an automatic feature, but the application and operating system have to support RPCs. In addition, the resource has to be available; you can't steal someone's resource if they're already using it. RPCs can include all kinds of resources, but they usually refer to code. You could borrow someone else's DLL if that DLL didn't appear on your machine, for example. The unique aspect of RPCs is that the code for that DLL would execute on the other person's machine, not on your machine. You would, in effect, borrow not only their code but their processor as well. Notice that this section doesn't define any light remote procedure call (LRPC) information. An LRPC is the same as an RPC except it deals with very specific types of resources and it always deals with code. You could borrow another person's DLL, but the code for that DLL would execute on your machine, not their machine. The LRPC statistics always appear as part of the OLE configuration information or within the RPC keys.
Unless you have a Microsoft mouse, you'll probably have a mouse-specific entryeven if your mouse doesn't provide Windows NT-specific software. Installing a Logitech mouse adds a Logitech key that provides mouse setup information as well as the driver version, for example. Usually, the key provides values that determine which buttons become assigned to various mouse functions.
Tip: Using the registry to edit a hardware configuration setting is almost always more flexible than using the Control Panel settings. What if you wanted to gain some additional control over your three-button Logitech mouse, for example? The default setup program enables you to assign a left- or a right-handed setup to the mouse. What if you wanted to exchange the right and middle button functions, essentially creating a two-button mouse? You could do so by transposing the MappingButton2 and MappingButton3 registry values even though the configuration utility doesn't provide the means to do so.
The Microsoft section of the SOFTWARE key provides some useful information as well. One of these keys is the New Users Settings key. Most 32-bit applications and some 16-bit applications can provide an entry in this area. A new user inherits these settings when you set up a new login on the machine. In essence, this key contains the global settings that everyone uses with this application (at least until they customize their setup). This key also provides the location of shared tools and any global network settings required to make the application work.
If you install any applications that support open database connectivity (ODBC), all those settings will appear under this key. ODBC is Microsoft's new method of enabling you to access information in foreign data formats. Its original main purpose was to allow access to mainframe databases, but you'll find it used to access other sources of information including those commonly found on a PC. Most programmers look at ODBC now as a method for generalizing access to any kind of database. You'll also see the 32-bit ODBC settings here. The strange thing is that they aren't identified using separate keys, even though the 32-bit settings appear as a separate icon in Control Panel. Every ODBC connection and its configuration appears under the ODBC | ODBCINST.INI key. The two important values are the name of the ODBC driver and its version. Most 32-bit drivers include a 32 somewhere in the filename. This allows you to separate the 32-bit drivers from the 16-bit drivers in this area.
The SCC key contains information about the viewers if you installed them. At first glance, you might not think that this key has anything worthwhile to see. The bottom of the hierarchy has two keys that both use descriptive value entry names such as Element 1. If you double-click one of these entries, however, you'll find the name of the DLL that controls it embedded in the binary data that each value contains.
One entry that you'll find here that you won't find in a Windows 95 registry is a Windows 3.1 Migration Status key. Under this key are two entries: IniFiles and REG.DAT. The first key tells Windows NT whether it has taken all of the .INI file data and placed it in the registry. The second key determines whether all the Windows 3.x registry data was incorporated into the registry.
The last registry key in the HKEY_LOCAL_MACHINE category is also the most destructive when edited incorrectly. A bad entry in any value under the System key can kill your installation. Figure 7.16 shows the subkeys associated with the System key. This setup is a lot more complicated than the one you'll find in Windows 95 because Windows NT has security and multiuser constraints to worry about. In addition, it doesn't provide the same flexibility through Plug and Play that Windows 95 does; everything has to be defined as part of the setup.
Figure 7.16. The System key provides much information and many opportunities for system optimization.
The main purpose behind the System section is device control. Complex devices require additional information to make them work. That's what you'll find in part in this subkey. Remember the REGISTRY value that I told you about as part of the DEVICEMAP key? The values in that section appear as keys here. Each one of those device maps appear in this section along with the current device mapthe one that you're using right this second.
Obviously, the System key has other types of information, too. Microsoft split these control set keys into four categories: Control, Enum, Hardware Profiles, and Services. Take a look at the Control key first. It contains all the subkeys that change the way the user reacts to the system as shown in Figure 7.17.
Figure 7.17. Each Control Set contains four subkeys, including the Control subkey shown here.
Warning: Exploring the System key part of the registry is somewhat risky. Some settings won't harm your system much; they might just change the text in a listbox or under an icon. Other settings will damage your Windows NT installation beyond repair, however, and still others will prevent access to your system. Wandering through this section and seeing what'll happen when you change a setting is one sure way to make your system unusable. Always make a backup of your registry before you make any change to this section.
One of the keys you'll see under the Control key is the NLS (national language support) key. Remember the keyboard setting I mentioned before? This is where all the language settings come from. If you had the correct driver, you could add support for Martian by changing the value of one of these keys. The network administration-specific keys appear under the Control key as well. One of the first keys you'll see is the computer name used to log onto the network.
[ic:Performance Issue]Several subkeys give the advanced user an opportunity to tune system performance. One of the most interesting keys is the Known16DLLs key under the SessionManager key. The values in this key tell you where you can optimize the system. A 16-bit DLL doesn't perform as well as its 32-bit counterpart. Finding 32-bit DLLs to replace the 16-bit DLLs in this section will improve your system performance without requiring you to buy any new hardware.
Tip: Not every 16-bit DLL is bad. You pay a price in program size when you use a 32-bit DLL. This translates to larger code size and actually means a decrease in performance. Most 32-bit DLLs offset this performance hit by offering more efficient code, however. In addition, 32-bit DLLs are more stable because of how Windows manages them. You should always base the decision to get rid of a specific 16-bit DLL on known performance improvement. Hoping you'll get something in return is like gambling: You never quite know if you'll win.
Now look at the Enum key. Below it, you'll find an HTREE and a Root key. The HTREE key contains a ROOT subkey, under which you'll find a list of configuration keys. Each configuration key contains a binary value that tells you what equipment that Windows NT has found attached to this system. In this case, this list is used for troubleshooting the system, not as part of an inventory. If you look at the Root key you'll see why. Below this key is a list of devices. Each device key also contains configuration keys. These configuration keys contain some human readable information such as the name of the device and the Windows NT service that supports it. This service is the same one that you see in the Control Panel. You'll even find the status flag that Windows NT displays in the Services dialog box here. A couple of other values could come in handy. The class identifiers for the device drivers are here, for example. You'll remember from the previous discussion in HKEY_CLASSES_ROOT that a class identifier is a 128-byte number used throughout the system. In this case, the identifier is for a piece of hardware instead of software.
The third subkey under the SYSTEM key is Hardware Profiles. You'll find one or more sets of configuration keys under this key that are identified with numbers. Along with these configuration keys is a Current key that contains the current configuration. When you select a hardware profile in the Control Panel, what you're really doing is copying the contents of one of these numbered keys into the Current keychanging the configuration of your system. Each of the configuration keys contains the setup information for the hardware you're using. You'll find the resolution of your display adapter here, for example. You won't find a complete hardware listing in this area; only the hardware with configuration settings appears in this section. For most people, that'll include their display adapter and not much more.
Move on to the fourth part of the System key, Services (see Figure 7.18). This group of keys does just the opposite of what the Control key section does: It allows the user to change the way the system reacts. There are a few keys in this group that you should never touch. They include Arbitrators, Unknown, and Nodriver.
Figure 7.18. The Services key displays a list of Windows NT services and their associated user settings.
The majority of the Services key subkeys provide useful information. The CDROM key can tell you about the drivers associated with the CD-ROM drive, for example. In some cases, it might provide clues about why the CD-ROM drive fails to play music or interface with the system in some other way.
The Display key contains several subkeys related to the display adapter. (You may actually find the contents of this key under a different key name. MGA display adapters use an mga key for data storage, for example.) This includes specifics about resolution and color combinations that the driver supports. (In one case, I was actually able to change this entry and provide 256-color support at 1024x768 resolution on one machine even though the driver originally showed that it didn't support this combination.) Of course, as with any other keys in this group, editing the values for this key can result in a boot failure or other unforeseen occurrences.
Besides these keys, you might find some network-related information under the System key as well. Anyone using the Microsoft Network support provided with Windows NT will see an MSNP32 key, for example. The values under this key contain information about the user setup and login information.
The HKEY_USERS category contains a static listing of all the users of this particular registry file. It never pays to edit any of the information you find in this category. You can use this category for reference purposes, however. The reason for this hands-off policy is simple: None of the entries here will take effect until the next time the user logs into Windows NT, so you really don't know what effect they'll have until you reboot the machine. In addition, changing the settings for the current user is a waste of time because Windows NT will overwrite the new data with the data contained in HKEY_CURRENT_USER during log out or shutdown.
One other problem is associated with using this category as your sole source of information. Windows NT actually maintains multiple registries in a multiuser configurationin some cases, one for each user who logs into the system. Because of this, you never quite know where you'll find the information for a particular user. Windows NT tracks this information, but it really is a pain for the administrator to have to do it as well. Besides, Microsoft thoughtfully provided a utility that helps the network administrator maintain the various registries. The Policy Editor utility enables the network administrator to maintain static user information with ease. Using the Policy Editor lets the network administrator bridge the various registry files on the system when each user provides his or her own Desktop configuration.
Note: One of the ways in which Windows 95 and Windows NT differ is that Windows NT uses a class identifier number for users in place of a user name. Although you could identify a specific registry user in Windows 95 just by looking at this section, it's nearly impossible to do so in Windows NT. The bottom line is that with only a user number as a means of identifying who owns this particular section of the registry, it wouldn't be in your best interest to modify it.
Figure 7.19 shows a setup that includes the default and one user-specific key. Each user entry contains precisely the same keys, but the values might differ from user to user. When a user logs into the network, Windows NT copies all the information in his profile to the HKEY_CURRENT_USER area of the registry. When he logs out or shuts down, Windows NT updates the information in his specific section from the HKEY_CURRENT_USER category.
Figure 7.19. Windows 95 creates one entry in the HKEY_USERS category for each user who logs into the machine.
Where does the original information for each user come from? The registry contains one entry called .Default. (Notice the period in front of the keyname. Default without a period is an actual user name.) Windows NT takes the information in this key and copies it to a user-specific key when the user logs in for the first time. Each profile will look precisely the same as the one provided for the .Default key. The user can't add new keys for his configuration.
Each subkey and value under the .Default key is echoed in the HKEY_CURRENT_USER category, so I won't discuss the settings again here. (The initial login does more work than create a simple registry entry, but this chapter doesn't cover that.) You should follow a few registry-related tips when setting up your network:
The HKEY_CURRENT_CONFIG category is the simplest part of the registry. It contains two major keys: Software and Settings. Essentially, these entries are used by the GDI API (described later) to configure the display and printer. (You might find other devices here such as scanners in some cases.) In most cases, the Software key won't contain any entries unless your display adapter or printer require special software to do their jobs.
The Settings key contains the current settings for the system. In most cases, you'll find the display resolution and number of bits per pixel here. The bits per pixel value determines the number of colors available. For example, 4 bits per pixel provides 16 colors, and 8 bits per pixel provides 256 colors. The three fonts listed as values under this key are the default fonts used for icons and application menus. You can change all the settings under this key using the Settings tab of the Properties for Display dialog box found in the Control Panel. Figure 7.20 shows the major keys in this category.
Figure 7.20. The HKEY_CURRENT_CONFIG category echoes the settings under the Config key of the HKEY_LOCAL_MACHINE category.
Explorer is the Windows NT alternative to the Windows 3.x File Manager. It goes a long way toward making Windows NT truly usable. As with any other tool, though, you'll probably want to customize Explorer to meet your needs. One of the first things you'll want to do is change the file associations.
The problem with Explorer is that you can't add new extensions to an existing file type. This means that if you want to extend the ability of Word for Windows to open file types other than the default types, you can't do it with the tools that Explorer provides. You can still get the job done using the Registry Editor, however. The following simple procedure will enable you to add new extensions to an existing entry. (I approach it from an exercise point of view to make the illustration clearer. Just substitute the values you need in place of the ones I provide here.)
Tip: Always use the right tool for the job. It might be tempting to use the Registry Editor to make all your file association changes. Using the Explorer interface is a lot faster, simpler, and less error-prone than making the modifications by hand, however. The only time you should use the Registry Editor on a file extension is when you need to extend an existing association.
Note: If you already have an .ASC extension in your registry, choose another extension for right now.
Figure 7.22. Word now provides four file associations, including the new ASC extension.
One of the things that really annoyed me when I started using Windows NT was that Microsoft prevented me from changing some namesand for no real reason. One of these was the name of the Recycle Bin. I'd prefer just about any name to that (and so would a lot of other people I've talked to).
You don't have to live with any names you really don't want under Windows NT. The vast majority of the titles that appear under icons and, in some cases, even the items you'll see in a listbox are all in the registry. The following simple procedure will use the Find command to help you locate the offending string and change it.
Warning: Windows NT relies on the contents of some strings to perform specific work. You might change your network name, for example, and it will work fine; then, in other cases, it won't work at all because your network embedded that name in a file. Changing a string without knowing how it affects your computer is never a good idea. Change only the strings that contain names you can see. Icons and some listboxes are good candidates.
As with the preceding section, I approach this from an exercise perspective. I've kept things as simple as possible so that you can use this procedure to modify other names you might not like.
That's all there is to it. You can use this procedure for a variety of tasks, including changing names you don't like. The same word of caution applies here as it does everywhere else. If you do decide to change the registry, be sure to make a backup first. Trying to restore a failed registry is pretty much impossible under Windows NT.
One of the problems with using a registry for everything is that you have to put the configuration data into a form that the registry can accept. Quite a few mainstream applications create a .REG file that you can import into the registry. Even the .REG files created with 16-bit applications are compatible with the Windows NT registry.
You can use several techniques to import your current registry information into the registry. First, you can open a copy of Explorer and find the registry file you want to import. Figure 7.24 shows a typical example.
All you need to do is double-click the REG icon (shown as Winword6.reg in Figure 7.24), and RegEdit automatically enters it into the registry. Notice that the REG file icon looks like the Registry Editor icon with a document behind it. After the registry enters the new configuration information for your application, it displays the dialog box shown in Figure 7.25.
Figure 7.24. A typical registry file entry for Word for Windows 6.0.
Figure 7.25. The registry signals a successful configuration data entry for Word for Windows 6.0.
A second technique comes in handy when you have the Registry Editor open. Simply select Registry | Import Registry File. The Registry Editor will display a dialog box similar to Figure 7.26.
Click the Open button to complete the task. You should see the same dialog box shown in Figure 7.25 when RegEdit completes the task.
Figure 7.26. You can use menu commands to import configuration into the registry when RegEdit is open.
What happens when you want to save some configuration changes you made in the past? What if you added a new file extension to the registry and want to save those entries for future use, for example? How about the custom color combinations that you createwouldn't it be nice to save them before installing a new version of Windows NT? You can export either all or part of the registry by using the Registry | Export Registry File command in the Registry Editor. Figure 7.27 shows the Export Registry File dialog box.
Figure 7.27. The registry provides the means to export configuration data into a pure ASCII text file.
Notice that this dialog box has the All radio button selected. This option saves the entire registry to a text file. Use this option when you want to save the registry before you start editing it. It's also easy to save a branch (or section) of the registry. When you click the Selected Branch radio button, you can either highlight the branch you want to save before you open the Export Registry File dialog box or type the path in later.
All you need to do to complete the process is click the Save button. RegEdit doesn't provide any kind of feedback once it exports the registry to disk. You'll probably want to view the saved file before you make any changes to the registry.
Exported registry data files contain pure ASCII text. They don't contain any control characters that you need to worry about. You usually need to use Wordpad to view a save of the entire registry. (A full registry export file normally takes between 400KB and 500KB of storage.) Notepad will probably do the job if you want to look at a saved branch.
Figure 7.28 shows a typical saved registry branch. Notice that this file has three lines. The first line contains REGEDIT4, which identifies the version of the Registry Editor that created the file. It also prevents you from importing the file into an older version of the registry. Application .REG files normally don't contain any version numbers as part of the REGEDIT entry, which enables you to import them using any version of RegEdit.
Figure 7.28. Each line of this saved registry branch serves a specific purpose during the import process.
The real second line of the file contains a blank. RegEdit uses this blank line as a delimiter between registry key entries. The second line of text (the third line of the file) contains the registry key. Notice that it looks like a hard disk directory listing. Each backslash tells RegEdit to create a new key level.
The final line of text contains the actual key value. The @ symbol at the beginning of the line tells RegEdit that this is the default entry. Any other value begins with a value name. The double quotes around the value itself tell RegEdit that this is a string value. Binary values begin with the word hex followed by a colon, and DWORD values begin with the word dword followed by a colon.
Tip: You might find that you need to add the keys from one branch to another branch in the registry. You might want to use some of the OLE information from one file association when creating a new one, for example. It seems like RegEdit should provide some type of cut-and-paste capability to take care of this task, but it doesn't. The fastest, most efficient way to add the contents of one branch to another is to export the registry, use a text editor to cut and paste the values you need, and import the modified registry file. Of course, you could find yourself with a machine that won't boot using this method. Make sure you keep an unmodified copy of the registry handy just in case.
Windows NT is a powerful operating system designed to meet a lot of heavy computer usage needs. Microsoft's original intent was to relegate Windows NT to the needs of power users such as engineers and programmers. Slow Windows 95 sales and a lot of conversation from their users has convinced Microsoft that Windows NT is the operating system of choice for corporate America.
Trying to manage all of those computers, especially in a large company, could become a very difficult task. A network administrator needs the proper tools to get the job done. The RegEdit utility might look like a low-level tool designed for use on the local computer; the first part of that perception is correct, but the second part isn't.
If you're an administrator, you can modify the registry of another machine as long as you meet three criteria. First, both machines must be running the Microsoft Remote Registry service. I'll show you how to install this driver later in this section. Second, you must have a copy of the RegEdit utility and have full access rights to it. I'm going to discuss some Windows NT features in the next section that might prevent you from gaining full access to the RegEdit utility even though you do have partial access. Third, you must have the proper access rights on both machines. This means that you have to enable specific operating system features and be on the list of those who can modify the registry.
Take a look at the first requirement. Windows NT doesn't automatically add the Remote Registry service as a default. In fact, Microsoft buries the documentation for this service on the resource kit disk and within a README file on the distribution disk. You won't find any mention of this service in the standard documentation. There's actually a good reason for all this secrecy. Just think about the power that a user has when they have access to the registry. Now, what would happen if that same user gained access to all the registries on the network? I just outlined all the settings that the registry containsso it shouldn't take too much time to figure out why Microsoft keeps the Remote Registry service a deep, dark secret.
You'll find the Remote Registry service files in the \ADMIN\NETTOOLS\REMOTREG folder of your distribution disk. Installing it is a snap. Just follow the procedure for adding a new network service in the section "Adding New Services or Other Features" in Chapter 22 "Peer-to-Peer Networking."
Note: If you want to access the registry on a Windows 95 workstation, you have to set up the workstation for User Level Access Control on the Access Control page of the Network properties dialog box. Make sure you provide the name of the workstation's main file server. The workstation will use this file server as a source of users and groups. You must appear as an administrator on the file server you select.
The final piece of this puzzle is the RegEdit utility. You'll find a Connect Network Registry option on the File menu. Select this option and you'll see the Connect Network Registry dialog box shown in Figure 7.29.
Figure 7.29. The Connect Network Registry dialog box allows you to specify which computer's registry you want to view.
You can use the Browse button to display a list of machines currently on the network. All you need to do is select the name of the computer that you want to see and then click OK to add it to the Computer Name field of the Connect Network Registry dialog box.
Click OK. Windows will display an hourglass icon for a few minutes while it makes the connection and downloads the other computer's registry. What you'll see when you get finished is the other computer's registry below your own as shown in Figure 7.30. Notice that the other computer uses a different icon from your own.
Figure 7.30. The other computer's registry appears below your own, using a different icon to signify that it's a remote registry.
Now that you've made a connection, you can make any changes to the remote registry that you can make to your ownwithin certain limits. A network administrator can put certain areas of a registry out of bounds for you. The next section of the chapter looks at this particular issue.
The final registry topic for this chapter is security. I'm not going to go through every security issue here; I cover a lot of these issues in the networking sections of the book (Part VI, "Networking with Windows NT"). What I want to do is make you aware of some features that Windows NT provides that you won't find in Windows 95.
A network administrator can protect a Windows NT workstation in several different ways. Some of these options are open to Windows 95 users as well. Because you can administer a registry from a remote location, for example, you can simply remove the copy of RegEdit from a workstation. A user who doesn't have a copy of this utility won't be able to edit their registry. Of course, this won't work with a determined user; they'll simply bring a copy of the program from home. (The same problem occurs if you limit access to the RegEdit file through the Security page of the RegEdit Properties dialog box.)
Modifying the registry also requires certain rights under Windows NT. As a default, only the administrator group has these rights. A power user might be able to view the contents of the registry, but they'll receive an error message like the one shown in Figure 7.31 if they try to change it. Ultimately, this is the level of protection that you'll needgiving rights to users only when they absolutely have to have them to get their job done.
Figure 7.31. Not having the Administrator group rights will allow you to view many areas of the registry but not change them.
Use the Registry Editor to create a copy of your registry using the procedure found in this chapter. Make sure you store this text copy of the registry in a safe place.
The registry is a central part of Windows 95. You can't do anything without it. Explore the registry using the Registry Editor. What do the values associated with each of the keys tell you about your system's configuration? Make sure you exit the Registry Editor without making any changes to any of the keys.